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Remarks 

Claims 1, 5 through 8, 11 and 15 through 18 remain in this application. Claims 1, 8, 11 
and 18 are amended. Claims 21 and 22 are added. 

Claim Rejections under 35 U.S.C. $1 12 

The Office Action objected to claims 1 and 1 1 for antecedent basis for the phrase, "the 
memory address file." This typographical error has been corrected. 

Claim Rejections under 35 U.S.C. 3102 

Claims 1-20 were rejected under 35 U.S.C. 102(e) as being anticipated by U.S. 
Publication No. 20050259597 to Benedetto ct al. (the Benedetto reference). A claim is 
anticipated only if each and every element as set forth in the claim is found, either expressly or 
inherently described in a single prior art reference. The identical invention must be shown in as 
complete detail as contained in the claim. See M.P.E.P. 2131. Applicants respectfully traverse 
this rejection of the claims because the Office Action has failed to prove that the Benedetto 
reference discloses each element of the claims. 

Independent Claim 1 and dependent claims 5 through 7, 21 and 22 
The Office Action has failed to prove that the Benedetto reference discloses the elements 
of claim 1, inter alia, of, "in response to receiving a TCN, monitoring end host addresses in data 
units received from the customer network for a predetermined time period; flushing an address 
memory file associating end host addresses with ports of the provider edge bridge in response to 
detecting an end host address indicating that a topology change has occurred in one or more of 
the customer LAN segments affecting paths of data units through the provider network, wherein 
detecting an end host address indicating that a topology change has occurred comprises detecting 
a predetermined number of end host addresses of data units received in the predetermined time 
period is not found in the address memory file; and in response to determining a topology change 
in one or more of the customer LAN segments do not affect paths of data units through the 
provider network, storing a new address in the address memory file without flushing the address 
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memory file." The specification of corresponding US Published Application No. 20040174828 

states in paragraphs 1 1 and 12 that: 

"[001 1] Topology changes in the Customer VLAN can also require changes in the 
MAC address tables in the bridges of the provider network. A previous proposal 
allows snooping on all TCNs generated within the customer domain, and taking 
action indiscriminately. Each time a TCN is generated, the provider domain 
unlearns (flushes the MAC table of each bridge) and re-learns all the addresses. 
Re-learning the MAC address at each bridge is a costly and time-consuming 
operation. 

[0012] Therefore, a need has arisen for an efficient method of taking action inside 
the provider domain responsive to TCNs received from the customer domain. 

The specification of corresponding US Published Application No. 20040174828 states in 

paragraphs 33 through 37 that: 

[0033] FIG. lb illustrates a topology change that will affect the MAC address 
tables of the bridges in Site A, but does not affect the MAC address table in any 
of the provider bridges. In FIG. lb, the CB2-CB3 link is activated and the CE1- 
CB1 link is blocked. TCNs will be generated accordingly within the Customer 
VLAN 18 to indicate that changes have been made to the topology. TCNs are 
generated as a BPDU (Bridge Protocol Data Unit); if the TCN flag is set in a 
BDPU, it is interpreted as a TCN. The MAC address tables for CE1 and CB2 
must be changed in response to these TCNs, but the forwarding address in the 
provider bridges remain valid with regard to addresses X and Y. Therefore, 
unlearning address in the provider domain due these TCNs would be wasteful. 

[0037] The flowchart of FIG. 2a determines whether a TCN was generated for a 
topology change in the customer domain that may require unlearning/relearning 
operations in the provider domain, by checking for contradictory MAC address 
or new MAC addresses. However, receiving a new MAC address does not 
conclusively mean that the new address was received due to the topology change 
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indicated by the received TCN. A new MAC address could also indicate that a 
MAC address was not previously active. Thus, an unlearning operation could be 
unnecessary." 

The specification describes that in known solutions, each time a TCN is generated from a 
customer domain, a provider domain unlearns (flushes the MAC table of each bridge) and re- 
learns all the addresses. However, re-learning the MAC address at each bridge is a costly and 
time-consuming operation. An embodiment of the specification describes that a TCN generated 
from a customer domain may not require flushing of the MAC addresses in the provider domain 
when the topology change in the customer domain does not affect paths of data units through the 
provider domain. Thus, an embodiment determines whether the MAC addresses need to be 
flushed and relearned in a provider domain in response to a TCN from a customer domain. If the 
topology change in the customer domain does not affect paths of data units through the provider 
domain, then the MAC addresses in the address memory file are not flushed and relearned. 

The Office Action cites Figure 2 and paragraphs 19, 92 and 113 of the Benedetto 
reference for disclosing these elements of the claims. The Benedetto reference states in 
paragraph 17 that: 

If a bridge stops receiving BPDU messages on a given port (indicating a possible 
link or device failure), it will continue to increment the respective message age 
value until it reaches the maximum age threshold. The bridge will then discard the 
stored BPDU information and proceed to re-calculate the root, root path cost and 
root port by transmitting BPDU messages utilizing the next best information it 
has. The maximum age value used within the bridged network is typically set by 
the root, which enters the appropriate value in the maximum age field 126 of its 
transmitted BPDU messages 100. Neighboring bridges similarly load this value in 
their BPDU messages, thereby propagating the selected value throughout the 
network. The default maximum age value under the IEEE standard is twenty 
seconds, [emphasis added] 

The Benedetto reference clearly indicates in this paragraph 17 that a bridge will discard stored 
BPDU in formation if a bridge stops receiving BPDU messages on a siven port for a maximum 
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age value threshold. In paragraph 19, the Benedetto reference reiterates this disclosure and 
states that: 

To prevent bridges from distributing messages based upon incorrect address 
information, bridges quickly age-out and discard the "old" information in their 
filtering databases. More specifically, upon detection of a change in the active 
topology, a bridge begins transmitting Topology Change Notification Protocol 
Data Unit (TCN-PDU) messages on its root port. The format of the TCN-PDU 
message is well known (see IEEE 802. ID standard) and, thus, will not be 
described herein. A bridge receiving a TCN-PDU message sends a TCN-PDU of 
its own from its root port and sets the TCA flag 1 12 in BPDUs that it sends on the 
port from which the TCN-PDU was received, thereby acknowledging receipt of 
the TCN-PDU. By having each bridge send TCN-PDUs from its root port, the 
TCN-PDU is effectively propagated hop-by-hop from the original bridge up to the 
root. The root confirms receipt of the TCN-PDU by setting the TC flag 1 14 in the 
BPDUs that it subsequently transmits for a period of time. Other bridges, 
receiving these BPDUs, note that the TC flag 114 has been set, thereby alerting 
them to the change in the active topology. In response, bridges significantly 
reduce the aging time associated with their filtering databases which, as described 
above, contain destination information corresponding to the entities within the 
network. Specifically, bridges replace the default aging time of five minutes with 
the forwarding delay time, which by default is fifteen seconds. Information 
contained in the filtering databases is thus quickly discarded. 

Thus, in response to a TCN-PDU, the Benedetto reference discloses that information contained 
in the filtering databases is thus quickly discarded. There is no discussion of determining 
whether the MAC addresses need to be flushed and relearned in a provider domain in response to 
a TCN from a customer domain. There is no discussion that when the topology change in the 
customer domain does not affect paths of data units through the provider domain, then the MAC 
addresses in the address memory file are not flushed and relearned. As such, the Benedetto 
reference fails to describe, inter alia, the requirements of claim 1 of, "and in response to 
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determining a topology change in one or more of the customer LAN segments do not affect paths 
of data units through the provider network, storing a new address in the address memory file 
without flushing the address memory file." 

In conclusion, the Benedetto reference fails to disclose each element of the independent 
claim 1 and thus fails to anticipate claim 1 under 35 U.S.C. 102(e). Claims 5 through 7, 21 and 
22 add further patentable matter to Claim 1 and thus are further differentiated and patentable 
under 35 U.S.C. §102 over the Benedetto reference. 

Independent Claim 8 

The Office Action has failed to prove that the Benedetto reference discloses the elements 
of claim 8, inter alia, of, "determining whether a topology change in the customer LAN segment 
affects paths of data units through the provider network; when a topology change docs not affect 
paths of data units through the provider network, transmitting unflagged topology change 
notifications (TCNs); when a topology change affects paths of data units through the provider 
network, transmitting flagged topology change notifications (TCNs) which relate to the topology 
changes affecting paths of data units through the provider network." 

The Office Action cites Figure 2 and paragraphs 19 and 108 of the Benedetto reference 
for disclosing these elements of the claims. The Benedetto reference states in paragraph 19 that: 
[0019] As ports transition between the blocked and forwarding states, entities may 
appear to move from one port to another. To prevent bridges from distributing 
messages based upon incorrect address information, bridges quickly age-out and 
discard the "old" information in their filtering databases. More specifically, upon 
detection of a change in the active topology, a bridge begins transmitting 
Topology Change Notification Protocol Data Unit (TCN-PDU) messages on its 
root port. The format of the TCN-PDU message is well known (see IEEE 802. ID 
standard) and, thus, will not be described herein. A bridge receiving a TCN-PDU 
message sends a TCN-PDU of its own from its root port and sets the TCA flag 
1 12 in BPDUs that it sends on the port from which the TCN-PDU was received, 
thereby acknowledging receipt of the TCN-PDU. By having each bridge send 
TCN-PDUs from its root port, the TCN-PDU is effectively propagated hop-by- 
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hop from the original bridge up to the root. The root confirms receipt of the TCN- 
PDU by setting the TC flag 1 14 in the BPDUs that it subsequently transmits for a 
period of time. Other bridges, receiving these BPDUs, note that the TC flag 114 
has been set, thereby alerting them to the change in the active topology. In 
response, bridges significantly reduce the aging time associated with their 
filtering databases which, as described above, contain destination information 
corresponding to the entities within the network. Specifically, bridges replace the 
default aging time of five minutes with the forwarding delay time, which by 
default is fifteen seconds. Information contained in the filtering databases is thus 
quickly discarded. 

The Benedetto reference only describes that upon detection of a change in the active topology, a 
bridge begins transmitting Topology Change Notification Protocol Data Unit (TCN-PDU) 
messages on its root port. There is no description of determining whether a topology change in 
a customer LAN segment affects paths of data units through the provider network. 

Furthermore, the Benedetto reference describes that a TCA flag 112 in BPDUs is set 
thereby acknowledging receipt of the TCN-PDU. In general, a bridge acknowledges the 
reception of a TCN BPDU by setting the TCA flag in its next configuration BPDU. The 
Benedetto reference nowhere describes not setting the TCA flag or determining whether to set 
the flag depending on whether a topology change in the customer LAN segment affects paths of 
data units through the provider network. 

In conclusion, the Benedetto reference fails to disclose each element of the independent 
claim 8 and thus fails to anticipate claim 8 under 35 U.S.C. 102(e). 

Independent Claim 1 1 and dependent claims 15 through 17 

For similar reasons as stated with respect to claims 1 and 8, the Office Action has failed 
to prove that the Benedetto reference discloses the elements of claim 11. Claims 15 through 17 
add further patentable matter to Claim 1 1 and thus are further differentiated and patentable 
under 35 U.S.C. §102 over the Benedetto reference. 
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Independent Claim 18 and dependent claims 19 and 20 

For similar reasons as stated with respect to claims 1 and 8, the Office Action has failed 
to prove that the Benedetto reference discloses the elements of claim 18. 

Conclusion 

For the above reasons, the foregoing amendment places the Application in condition for 
allowance. Therefore, it is respectfully requested that the rejection of the claims be withdrawn 
and full allowance granted. Should the Examiner have any further comments or suggestions, 
please contact Jessica Smith at (972) 240-5324. 

Respectfully submitted, 

Garlick Harrison & Markison 

Dated: May 31. 2009 /Jessica Smith/ 

Jessica W. Smith 
Reg. No. 39,884 

Garlick Harrison & Markison 
P. O. Box 160727 
Austin, TX 78716-0727 
Phone: (972)240-5324 
Fax: (888)456-7824 
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